logo

blog

My website can't be that messy, right? git clone https://hacktivis.me/git/blog.git

Repo-less packages, Docker, AppImage and others curl|sh.xhtml (3803B)


  1. <article xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" class="h-entry">
  2. <h1 class="p-name">Repo-less packages, Docker, AppImage and others curl|sh</h1>
  3. <p>Seriously, after <a href="http://breizh-entropy.org/wiki/systemd">SystemD</a>OS, what could I except for thoses LazyUSERS trying to act as system-admin (sorry to people that need to work with thoses tools).</p>
  4. <p>I know theses tools can help thoses that doesn’t want/know-how to do sys-admin, but seriously. Most people do know how to use a package manager to install few apps. (Otherwise people would not use App Store, Android Market^W^WPlay Store and various organisations would not try to use them for whatever product).</p>
  5. <p>Also with this types of tools(I’ll call them lazy-pkgs) you reduce security to almost nothing. Yes, AppImage doesn’t use root privileges, it doesn’t make it unharmfull, it can still do damage (like bumblebee/optimus and steam removing everything in the home directory). Yes, docker binairies doesn’t directly use the kernel and already available tools, well how do you expect lazy-pkgs to manage security flaws? (Try to imagine another heartbleed, shellshock, …). I heard docker as a daemon(which looks like a systemd clone that works on top of systemd, how meta).</p>
  6. <p>For a simple comparison here is what package managers I met for a long time have:</p>
  7. <ol>
  8. <li>Security updates (security.debian.org // unattended-upgrades, emerge -a @security, …)</li>
  9. <li>The Source/Binairies of the package</li>
  10. <li>For Binairies: How it’s builded</li>
  11. <li>Some patches and extra software (rc script, systemd-service.xml)</li>
  12. <li>Verification (hashes or better, OpenPGP)</li>
  13. <li>Dependencies (I know theses are horrible, but removing a warning light won’t remove the warning, otherwise just unplug your machine)</li>
  14. <li>Scripts for compiling, (un)installating, configuring, updating</li>
  15. <li>Meta-data (like description, homepage, issues, source code repository, …)</li>
  16. <li>Stability (in debian it’s per repo but in Gentoo it’s in the package ebuild)</li>
  17. </ol>
  18. <p>And here is what lazy-pkg have(From what I’ve heard, as I don’t want theses.)</p>
  19. <ol>
  20. <li>Binairies (poor BSDists)</li>
  21. <li>If not included, dependencies(on a specific repo, like alpine for docker)</li>
  22. <li>Some have verification (but mostly sucks)</li>
  23. <li>Scripts for compiling, (un)installating, configuring, updating (or even services/RC like docker)</li>
  24. </ol>
  25. <p>Well, not hard to notice that it as many thing removed. Poor security, customisation and filesystem tidyness(as packages are no longer managed by a tool). It’s somewhat even worse than Windows (XP, dunno later versions) as with this horrible-ness you still had dependencies(.NET Framework, DirectX, VisualBasic, …) and you still could remove and choose a bit of what’s in your system. Now if the NSA, DGSI, GRU or any other government (secret) agency want a huge backdoor they just have to ask the maintainer, even less people would notice as it’s more obscure.</p>
  26. <p>Also, for the time being lazy-pkgs are being used by commonly trusted organisations. But what if non-trusted but mandatory(like drivers) organisations start using your tools like they so badly do with .deb and .rpm (and sometimes with tarballs)</p>
  27. <p>I understand the idea of doing one package for tons of distros, but you’re doing it wrong. I think if you still want lazy-pkgs you should make/re-use a separate package manager(like pip for python, luarocks for lua, gem for ruby, …).</p>
  28. <p>Anyway stay with Blob, I’ll keep building everything from source (so I can verify it’s really Open-Source), even non-executables like documentation and keep blobs into a separate system and say that I want OpenPGP for the gentoo repo.</p>
  29. </article>